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1 1 Overview 

2 This document provides the architecture of the MOTOTRBO™ Text Messaging Service 

3 (TMS) and data interface to the TMS. The following are the major chapters of this 

4 document: 

5 • Overview of the TMS architecture 

6 • TMS Functionality offered by the MOTOTRBO™ radio 

7 • Data interface and Presence interface description to the external TMS application 

8 • Customer Programming Software (CPS) provisioning of the TMS 

9 1.1 Purpose 

to This document is intended to be used by a third party developer to create external TMS 

11 applications that integrate with the MOTOTRBO™ radio. It provides the system level 

12 details of the main TMS components, it also provides information on the interoperability 

13 between the functions provided by the TMS and its components. 

14 1.2 Assumptions 

is It is assumed that the reader of this documentation has the following domain 

16 knowledge: 

17 • Principles of two-way radio communications 

is • Procedural or Object-Oriented Programming 

19 • Transmission Control Protocol / User Datagram Protocol (TCP / UDP) 

20 • Internet Protocol (IP) 

21 • Universal Serial Bus (USB) 

22 

23 The following domain knowledge is considered beneficial, but is not required: 

24 • Open Systems Interconnection (OSI) Model 

25 1.3 References 

26 [1] MOTOTRBO™ Text Messaging Protocol Specification 

27 [ 2 ] MOTOTRBO™ Data Services Overview 

28 [3] MOTOTRBO™ Option Board ADK Guide 

29 [4] MOTOTRBO™ XCMP/XNL Development Guide 

30 [5] MOTOTRBO™ Presence Notifier to Watcher Interface Specification 

31 [6] MOTOTRBO™ ARS Specification ADK Guide 
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32 1A Terminology 

33 Application Layer (OSI Layer 7) - this layer supports application processes. 

34 Big Endian - an order in which the "big end" (most significant value in the sequence) is 

35 stored first (at the lowest storage address). For example, in a big-endian computer, the 

36 two bytes required for the hexadecimal number 4F52 would be stored as 4F52 in 

37 storage (4F at address 1 000, 52 at 1001). 

38 Broadcast - an unsolicited message that is sent to one or more recipients. 

39 CDC-ACM - Communications Device Class-Abstract Control Module 

40 Confirmed Delivery Channel - any communications channel that provides confirmation 

41 to the sender when the receiver receives its data correctly. 

42 CR - carriage return (OxODOO), UCS2-LE formatted. 

43 Data Link Layer (OSI Layer 2) - this layer encodes and decodes the data packets. It 

44 furnishes transmission protocol knowledge. 

45 Direct Routing - it is used when the source and destination addresses have the same 

46 network number, the packet must not be forwarded. 

47 Indirect Routing - it is used when the source and destination addresses do not have 

48 the same network number, the packet must be forwarded by a node that knows how to 

49 reach the destination. 

50 IPv4 - Internet Protocol version 4 

51 LF - line feed (OxOAOO) , UCS2-LE formatted. 

52 Little Endian - an order in which the "little end" (least significant value in the sequence) 

53 is stored first. For example, in a little-endian computer, the two bytes required for the 

54 hexadecimal number 4F52 would be stored as 524F (52 at address 1000, 4F at 1 001). 

55 MAC - Media Access Control 

56 Network Layer (OSI Layer 3) - this layer provides routing and forwarding services. It 

57 creates logical paths, known as virtual circuits, for transmitting data from node to node. 

58 Open System Interconnection (OSI) - a model which defines a networking framework 

59 for implementing protocols in seven layers. Control is passed from one layer to the next, 

60 starting at the top layer in one station, and proceeding to the bottom layer, over the 

61 channel to the next station, and back up the hierarchy. 

62 Packet - a block of transmitted data. 
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63 PC - Personal Computer. 

64 Physical Layer (OSI Layer 1) - this layer conveys the bit stream {e.g. electrical 

65 impulse, light or radio signal) through the network at the electrical and mechanical level. 

66 It provides the physical means of sending and receiving data. 

67 Presentation Layer (OSI Layer 6) - this layer formats and encrypts data to be sent 

68 across a network, providing freedom from compatibility problems. 

69 Reply - a message that is sent in response to a Request message. 

70 Request - a message that expects an immediate reply 

71 Reliable Channel - any communications channel that provides a mechanism to detect 

72 and optionally correct an error in data received over the communications channel. Some 

73 errors may not be possible to detect or correct. A reliable channel simply provides more 

74 reliability above and beyond an unreliable communications channel. 

75 Response - a message that is sent as result of a previous message. A response could 

76 be a reply or broadcast message 

77 RF - Radio Frequency. 

78 Session Layer (OSI Layer 5) - this layer establishes, manages and terminates 

79 connections between applications. 

80 Simple Mail Transfer Protocol (SMTP) - a protocol for sending e-mail messages 

81 between servers. 

82 SUID - Subscriber Unit ID 

83 Transport Layer (OSI Layer 4) - this layer provides transfer of data between hosts. 

84 TGID - Talk Group ID 

85 UCS-2 LE - Universal Character Set coded in 2 bytes with Little Endian byte order. 

86 Unreliable Channel - a communication channel that provides no means for a receiver 

87 to detect communication errors. 

88 XCMP - Extended Control and Management Protocol. 

89 XNL - XCMP Network Layer. 
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90 2 Text Messaging Service Architecture 

91 2.1 Overview 

92 The MOTOTRBO™ radio provides a User Datagram Protocol (UDP) port through which 

93 an external PC application may communicate using the Text Messaging Service (TMS) 

94 protocol. This protocol is used to transport simple text messages between a PC-based 

95 application and one or more MOTOTRBO™ subscribers. Please note that the TMS is 

96 only available when the MOTOTRBO™ radio is operating in digital RF mode. 

97 Additionally, the TMS may be accessed as part of an integrated feature set provided by 

98 an option board-based application. Please see References [2] and [3] for more details. 

99 Figure 1 shows the architecture diagram for a typical configuration for Text Messaging 

100 between a radio-attached PC application as well as some other MOTOTRBO™ 

101 Subscriber Unit (SU) in the Radio Network. 



103 


Figure 1 - Text Messaging Service Interface Architecture 


104 In this architecture, the TMS application shown in this diagram can be some stand- 

los alone PC application or some client-server application that interfaces with a 
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106 MOTOTRBO™ radio in order to transport text messages through the radio’s Common 

107 Air Interface (CAI). For radio network bandwidth efficient operation, the TMS application 

108 may interoperate with a Presence Notifier (PN) in order to be informed of the 

109 registration / de-registration of subscriber units. See section 2.4 for more information. 

no Please note that specific Customer Programming Software (CPS) provisioning is 

111 required in order to ensure proper TMS operation as depicted in Figure 1. Please see 

112 section 5 for more information on CPS programming. 

113 2.2 interface to Text Messaging Service Application 

114 For a PC-based TMS application, the PC will be physically connected to a 

115 MOTOTRBO™ radio though a USB connection. 



116 

117 Figure 2 - Interface between External TMS Application and MOTOTRBO™ Radio 

118 UDP / IP are used as the transport and network layers for communication between the 

119 PC-based TMS application and the TMS component in the radio. Both the radio and 

120 PC-based application listen on UDP port 4007 for Text Messaging Protocol (TMP) 

121 messages. These TMP messages are in turn sent by the locally attached radio (acting 

122 as a data modem) to other MOTOTRBO™ subscriber units. The target radios are 

123 addressed in the UDP packet by IP address and port number (4007). The specified IP 

124 address can address an individual subscriber unit or a group of subscriber units. The 

125 UDP port 4007 can be configured to a different number through CPS if there is a port 

126 number conflict. 
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127 2.3 Interface to Option Board 

128 For TMS integration with an option board-based application, the MOTOTRBO™ radio 

129 provides a proxy service through which the option board can send and receive UDP / IP 

130 packets. UDP port 4061 is reserved for option board use of the TMS. The option board 

131 uses XCMP / XNL over the Synchronous Serial Interface (SSI) to communicate with the 

132 proxy service. Specifically, an XCMP data session is used to transfer data between the 

133 option board and the TMS proxy. Please see References [2] and [4] for more 

134 information. 



135 

136 Figure 3 - Interface between Option Board and MOTOTRBO™ Radio 

137 To send a text message from the option board to some other MOTOTRBO™ subscriber 

138 in the radio network, the option board formats the text message with the IP address and 

139 UDP port number (4007) of the target subscriber. The target subscriber can be another 

140 MOTOTRBO™ radio or a PC-attached MOTOTRBO™ radio. The text message is 

141 routed to the proxy service as a XCMP data session. The radio forwards the text 

142 message over-the-air as a UDP payload with source port number set to the option 

143 board’s text messaging proxy port (4061) and destination port number set to 4007 for 

144 the target subscriber. 

145 This process is reversed when an option board-integrated MOTOTRBO™ radio 

146 receives a text message from some other subscriber in the radio network. 
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147 2.4 Interface to Non-tP Peripheral 

148 For TMS integration with a non- IP peripheral-based application, the MOTOTRBO™ 

149 radio provides a proxy service through which the non-IP peripheral can send and 

150 receive UDP / IP packets. UDP port 4066 is reserved for non-IP peripheral use of the 

151 TMS. The non-IP peripheral uses XCMP / XNL over CDC-ACM / USB to communicate 

152 with the proxy service. Specifically, an XCMP data session is used to transfer data 

153 between the non- IP peripheral and the TMS proxy. Please see References [2] and [4] 

154 for more information. 



155 

156 Figure 4 - Interface between Non-IP Peripheral and MOTOTRBO™ Radio 

157 To send a text message from the non-IP peripheral to some other MOTOTRBO™ 

158 subscriber in the radio network, the non-IP peripheral formats the text message with the 

159 IP address and UDP port number (4007) of the target subscriber. The target subscriber 

160 can be another MOTOTRBO™ radio or a PC-attached MOTOTRBO™ radio. The text 

161 message is routed to the Proxy Service as a XCMP data session. The radio forwards 

162 the text message over-the-air as a UDP payload with source port number set to the 

163 non-IP peripheral's text messaging proxy port (4066) and destination port number set to 

164 4007 for the target subscriber. 

165 2.5 Interface to Presence Services 

166 Presence Services can be used in conjunction with a TMS application to efficiently 

167 utilize the Radio Network bandwidth. Presence Services may be added to the Customer 

168 Enterprise Network (CEN) through the use of the MOTOTRBO™ Presence Notifier (PN) 

169 or a 3rd party Automatic Registration Service (ARS) application. Please note that 
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Presence Services is only available when the MOTOTRBO™ radio is operating in digital 
RF mode. Please see Reference [5] and Reference [6] for more information. 


1 . Subscription 

2. Registration 



Figure 5 - Interoperability with Presence Notifier 

Figure 5 shows the interaction of the MOTOTRBO™ PN with a TMS application. The 
PN accepts radio presence information, stores it, and then distributes it to a TMS 
application that subscribes to receive presence notification. The intent of Presence 
Sen/ices is to allow radios to announce their availability within the Radio Network to 
applications existing in the CEN. The presence information of a MOTOTRBO™ radio is 
useful when an application needs to send a message to the subscriber unit 
asynchronously and results in efficient bandwidth utilization of the Radio Network. 
Please see section 4 for more information on the Presence Notifier. 

Please note that the ARS protocol does not have a mechanism to provide a status 
change when a subscriber unit temporarily leaves the area of coverage. Also, the 
presence status of a subscriber unit may be incorrect if powered off in an unexpected 
manner (e.g.. loss of power, low battery, etc.). The Presence Service is comprised of 
two components: 

1 . Automatic Registration Service (ARS) - Located in the MOTOTRBO™ radio. On 
radio power on as well as periodically and upon re-entry into digital RF mode, 
ARS registers the radio with the Presence Services application (MOTOTRBO™ 
PN or 3rd Party ARS application). ARS will also de-register the radio from the 
Presence Services on power off. 

2. MOTOTRBO Presence Notifier (PN) / 3rd Party ARS Application - Located in the 
Customer Enterprise Network (CEN). A TMS application subscribes with the 
Presence Services application (MOTOTRBO™ Presence Notifier or 3rd Party 
ARS application) to be informed of the presence events of specific radios. On the 
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197 change in status (i.e. presence to absence or absence to presence) of any 

198 particular radio, the Presence Services application sends a notification to the 

199 TMS application. The notification will contain the IPv 4 address of the 

200 MOTOTRBO™ radio. A Presence Services application may co-exist with a TMS 

201 application in same PC environment. However, use of the MOTOTRBO™ 

202 Presence Notifier or a 3 rd Party ARS application is mutually exclusive within the 

203 same CEN. 


Version 01 .01 


Motorola Confidential Proprietary 


13 




MOTOROLA 


MOTOTRBO™ 
Text Messaging ADK 
Guide 


204 3 Text Messaging Operations Offered 

205 This section briefly describes the text messaging functionality available in the 

206 MOTOTRBO™ radio. These functions are divided into two categories: (1) Gateway / 

207 Server operations and (2) Client / Subscriber operations. Please see Reference [1] for 

208 more information. 


209 3. 1 Gateway / Server Operations 

210 These operations are not supported directly by any MOTOTRBO™ subscriber unit and 

211 can only be initiated by a PC-based application attached to the radio. The operations in 

212 this category are used by a PC application that is acting as a gateway to another 

213 enterprise network and / or acting as a server for enhanced text message delivery. 

214 Gateway / Server operations include: 


215 

216 

217 

218 
219 


• TMS Service Availability - Announces availability of a TMS gateway or server on 
the Radio Network. May also provide expanded information indicating what 
gateway services are available. This message is sent to each subscriber unit that 
registers onto the Radio Network. Normally used in conjunction with Presence 
Notification. Please see Reference [5] for more information. 


220 3.2 Ciient / Subscriber Operations 

221 These operations are supported directly by all MOTOTRBO™ subscriber units. Any PC- 

222 based application functioning as a peer to any subscriber unit within the Radio Network 

223 must also support these operations. Client / Subscriber operations include: 


224 • Simple Text Message - Delivers a text message to an individual user or a group 

225 of users. Confirmed delivery may be used with an individual message but is not 

226 required. Confirmed delivery is not recommended for group messages in order to 

227 minimize air resource bandwidth / contention issues. 

228 

229 By default, the PC-based application must send less than 14 text messages per minute 

230 per channel to avoid channel overload. This number is a default value and maybe 

231 decreased or increased based on system usage and the number of channels available. 

232 However, the application may be unaware of the channel upon which the message is 

233 sent. Therefore it can not be guaranteed that a particular channel won’t be overloaded if 

234 the default is increased in a multi-channel configuration. The PC-based application must 

235 implement its own mechanism for “flow control” in all possible conditions. 

236 Also, the minimum interval between two consecutive messages from the PC-based 

237 application to the attached radio must be 1 200ms per channel. 
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During scan operation, the TMS of the radio will temporarily suspend the scan in order 
to send or receive text messages. Upon completion of text protocol communication, 
scan operation will resume. Please note that the transmission or reception of the text 
protocol messages will only occur on the radio’s home channel. And the voice 
communication always has higher priority than the text protocol communication. 

If the target subscriber unit is in a voice call, the source subscriber unit will start a timer 
to wait for the channel to be free, if the channel is free before the timer expires, the 
message will be sent to the target subscriber unit. 

3.3 Message Acknowledgement 

With the exception of unconfirmed delivery of Simple Text Messages, all other 
operations have a corresponding acknowledgement. 

• TMS Service Availability Acknowledgement - Sent by a subscriber unit or radio- 
attached PC in response to a TMS Service Availability message following 
registration onto the Radio Network. 

• TMS Acknowledgement (Success) - Sent by a subscriber unit or radio-attached 
PC to positively acknowledge receipt of a text message. Should only be sent if 
the Simple Text Message requires confirmed delivery. 

There are sequence number fields in the Simple Text Message and TMS 
Acknowledgement, which are used to match the acknowledgement with the original 
Simple Text Messages. 

When acknowledgement is required, an Acknowledgement Reply Timeout Timer at the 
application layer must be no less than 70 seconds. 

For both TMS Service Availability and Simple Text Message if acknowledgement is 
required and the sender does not receive the acknowledgement within predefined time 
period, the TMS Service Availability or Simple Text Message may be retransmitted with 
the same sequence number. See Figure 14 for more details. 
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264 4 Presence Interface for External TMS Application 

265 This section describes the Presence Notifier (PN) interface for an external TMS 

266 application running on a PC. Please note that use of the PN is optional. However, 

267 integrated operation with the PN will result in efficient bandwidth utilization of the Radio 

268 Network. 

269 Presence information is provided to an external TMS application that subscribes to 

270 receive presence notifications for any one MOTOTRBO™ radio. The transport protocol 

271 between the TMS application and the PN is UDP / IP. The TMS application must 

272 support a mechanism for configuration of the IPv4 address of the PN. On receipt of a 

273 subscription, the PN responds with the presence state and, if available, the IPv4 

274 address of the radio. 


275 The PN communicates with the Automatic Registration Service (ARS) component 

276 located in the radio using UDP / IP. The UDP port address of the ARS is 4005. A 

277 MOTOTRBO™ radio registers itself to the PN using the PN’s IPv4 address that is 

278 provisioned with the Customer Programming Software (CPS). Since the Radio Network 

279 may have more than one PN, it is not necessary for all subscriber units to register with 

280 the same Presence Notifier. 


281 

282 


1 . Subscription 

2. Registration 
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If the Automatic Registration Service is enabled in a MOTOTRBO™ radio, then the 
radio will register, at power on and periodically during operation, with the Presence 
Notifier. The radio also registers every time it re-enters the Radio Network (e.g. 
transition between analog RF and digital RF modes). In addition, upon power off, the 
radio de-registers with the PN. On successful registration by the subscriber unit, the PN 
will respond with an acknowledgement; no acknowledgement is sent for de-registration. 
The radio may make up to 5 total attempts to receive acknowledgement of its 
registration attempt. If acknowledgement is still not received, then registration is 
attempted every 30 minutes until acknowledged. 

When a subscriber unit successfully completes automatic registration, the PN status of 
the radio is “present”. If the subscriber unit fails to complete automatic registration at 
any point in time, the PN status of the radio becomes "absent.” 

Please note that successful registration remains valid with the PN for a specified 
duration. The expiration time is PN configurable with a default value of 4 hours. Upon 
expiration of the registration period, the MOTOTRBO™ radio will re-register with the 
PN. For those radios that successfully re-register and for those that don’t, the PN 
notifies any TMS application with subscriptions corresponding to the radios of interest 
with the updated presence state. 

The PN stores the presence state of each MOTOTRBO™ radio in persistent memory. 
Therefore, on startup, the PN uses the stored data to query only those radios whose 
registration has not expired. For any radio that fails to respond to the query, the PN 
updates the presence state to “absent” and notifies any TMS application with 
corresponding subscriptions accordingly. Please note that the Presence Notifier is not 
able to recover the presence state of a radio that powered on and whose last known 
state was “absent” while the Presence Notifier was off. 

To prevent catastrophic failure of the PN and any loss of presence states during “brown- 
out” or “black-out” conditions, it is recommended that the Presence Notifier’s PC 
environment operate with an Uninterruptible Power Supply (UPS). 

Please note that the Radio Information of any MOTOTRBO™ subscriber unit cannot be 
removed from the PN database once it is added. 

4. 1 Capacity of the Presence Notifier 

The Presence Notifier is capable of storing states and radio information of up to 400 
subscriber units and up to 1 0000 subscriptions from up to 25 applications. Note that it 
is not necessary to send an individual subscription for each radio. A list of radios 
(including a list of all radios) may be sent in the subscription request. A list of radios 
correspondingly reduces the total number of remaining subscriptions. 

The PN is capable of up to 64 subscriptions (and resulting notifications) per second 
when running on a PC with at least a 1GHz processor clock. Please note that a 
subscription may result in multiple notifications sent by the Presence Notifier. 
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322 The PN is capable of up to 4 registrations per second from radios on a PC having at 

323 least a 1 GHz processor clock. Please note that a registration may result in multiple 

324 notifications sent by the Presence Notifier. 

32s 4.2 Interface Details 

326 Please see Reference [5] for more information. 
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327 5 CPS Provisioning 

328 In order to route all the individual and group text messages through the MOTOTRBO™ 

329 radio (typically a mobile radio) to the local PC-based TMS application, the Network 

330 options of the radio must be configured for “Forward to PC” operation. 

331 When “Forward to PC” is checked, both individual and group text messages will be 

332 forwarded to the PC. When “Forward to PC" is not checked, individual text messages 

333 targeted for the PC will be routed to the PC. Group text messages and individual text 

334 messages targeted for the radio will be routed to the radio. 



336 Figure 7 - Radio-Wide Provisioning for “Forward to PC” Operation 
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6 Application Address 

In all of the Text Messaging message structures, there is an application address. It is 
used to support Enhanced PC-Based Text Messaging which includes sending 
messages to a Dispatcher client or to an external network address, and therefore 
involves the indirect addressing through the TMS Gateway. 

For messages sent from the radio network to an external network, the application 
address field indicates the destination address to the TMS Gateway. For messages 
received inside the radio network that originated from an external network, the TMS 
Gateway will supply the source address to the receiving device using the application 
address field. 

The addressing schema for devices in the radio network has the following format: 
< obiectlD.tvpe@domain> . 

• The object ID for a device will be its layer 2 ID (individual or talk group). Dispatch 
clients located on the customer enterprise network have a unique name for an 
object ID. 

• The type codes are parsed from the end of each address and are used for the 
following reasons: 

• To indicate to the subscriber unit how to address a message. The subscriber 
unit can associate a type with a direct or indirect routing address when 
sending a message. 

• To indicate to the TMS Gateway how to locate the destination for indirect 
routing. A message from the radio network that is destined to a Dispatch 
client type code will be routed properly by the TMS Gateway. A message from 
the radio network that is destined to an external address type code will be 
translated and routed by the TMS Gateway to an email server 

• To allow the differentiation between the individual ID and the talk group ID. 
The TMS Gateway will know how to determine if the destination IP address is 
for an individual subscriber unit or for a talk group based on the type code 

• The domain name is obtained by the TMS Gateway from an email server. It is 
unknown to the radio network. 

• The domain name must be used for external network address. Therefore when 
sending to the TMS Gateway from inside the radio network, the address will have 
the external network type appended at the end (i.e. username@domain . 6 
<mailto:username@domain.6 >). Upon translation, the TMS Gateway will remove 
the type code. When receiving an email from an external network address, the 
TMS Gateway will append the type code before routing into the radio network. 


Table 1 shows the addressing schema assignment in MOTOTRBO™ radio system. The 
Routing column indicates what mode is used for a message sent from a device inside 
the radio network to the device shown under the Receiving Object column. 
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Receiving Ob|ect 

ObJectID 

Type Code 

Routing 

Supported 

Destinations 


Device (SU or PC) 

SU's layer 2 ID 

1 

Direct 

Radio or 
External 
Application 


Talk Group 

Talk group layer 2 ID 

2 

Direct 


Dispatcher(s) (client) 

A name 

4 

Indirect 

External 

Network 

External Network 
Address 

username@domain 

6 

Indirect 

External 

Application 


379 Table 1 - MOTOTRBO™ Addressing Schema 

380 The following are the rules for the use of the application layer address in the 

381 MOTOTRBO™ radio: 

382 • Messages originating from a device (SU or Talk Group) to another device (SU or 

383 Talk Group) will NOT use the application layer address field. Addressing will reply on 

384 the underlying layers for the source and destination of the message. 

385 • Messages originating from a device (SU or Talk Group) to an indirect routing type 

386 code will use the application layer address field for the destination address. The 

387 underlying layers will be addressed to the TMS Gateway. 

388 • A message received by a device with the application layer address empty will use 

389 the underlying layers to identify the source address. 

390 • A message received by a device with an application layer address present will use 

391 that to identify the source address. 

392 

393 Table 2 is a summary for what addressing is used in each case. Messages that are 

394 indirect routing show the first hop addresses (to TMS Gateway) and the second hop 

395 addresses (to the destination) separated by a dashed line. The parenthesis next to the 

396 Layer 7 (L7) address indicated whether the application layer address field is the 

397 destination address (to TMS Gateway) abbreviated as “dest” or the source address (to 

398 the destination) abbreviated as “src”. 
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RECEIVING OBJECT 


SU or PC 

Dispatcher Client 

External Network 

SENDING 

OBJECT 

SU or PC 

L7: 

L3: derived IP 
12 : SUID orTGID 

L7: usemame.4 (dest) 
L3: TMS Gateway IP 
L2: SUID 

L7: 

username@domain.6 

(dest) 

L3: TMS Gateway IP 
L2: SUID 




L7: SUID.1 (src) 

L3: Dispatcher Client IP 
L2: MAC 




SMTP or other 


Dispatcher 

Client 

L7: SUID.1 orTGID.2 
(dost) 

L3: TMS Gateway IP 
L2: MAC 

L7: usemame.4 (dost) 
L3: TMS Gateway IP 
L2: MAC 

L7: 

username©domain.6 

(dest) 

L3: TMS Gateway IP 
L2: MAC 



L7: usemame.4 (src) 
L3: Dispatcher IP 
L2: MAC 



L7: usemame.4 (src) 
L3: derived IP 
L2: SUID or TGID 



SMTP or other 


External 

Network 

L7: SUID.1 ©domain or 
TGID.2@domain fdestl 
L3: IP routing 
L2: MAC routing 

L7: 

username. 4©domain 
(dest) 

L3: IP routing 
L2: MAC routing 

Not applicable 



L7: 

usernameOdomain .6 
(src) 

L3: derived IP 
L2: SUID orTGID 




L7: 

username@domain.6 

(src) 

L3: Dispatch IP 
12 : MAC 



400 Table 2 - Application Address Summary 

401 NOTE: For the interface between the Dispatcher client and the TMS Gateway, the 

402 address fields indicate the intended content, but not necessarily the intended format. 
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7 Character Display 

This section provides overview information about the character display on the 
MOTOTRBO™ radio. 

The MOTOTRBO™ radio will truncate any received text message destined to its TMS 
component that is over 140 characters {280 bytes) before the message is displayed on 
the subscriber unit. Also the maximum length of the text message composed from the 
MOTOTRBO™ radio is 140 characters. 

The radio user can scroll through the text message by using the left and right navigation 
buttons in both editing and viewing mode. The radio user can press and hold the left 
navigation button to scroll left character by character until the first character in the text 
message is reached. The radio user can press and hold the right navigation button to 
scroll right character by character until the last character in the text message is reached. 
The radio’s display panel can only display two lines at a time, therefore if the text 
message can not fit into two lines, there will be a right arrow displayed at the end of the 
second line to indicate that more text exists after the second line. A left arrow is 
displayed at the beginning of the first line to indicate that more text exists before the first 
line. See Figure 8 for an example. 


George: I'll be 
out of the office ► 

◄ out of the office 
for the rest of ► b 

◄for the rest of 
the week. 


Figure 8 - Example of Text Message Displayed In Multiple Lines 
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422 The MOTOTRBO™ radio only supports the UCS2-LE encoding schema. The 

423 characters that can be entered through the radio are shown in Figure 9 , which is the 

424 MOTOTRBO™ portable’s keypad. 



f2 ABC ] 

r, 

3 DEF 

l J 

^4 GHI ) (5 JKL ) [6 MNO^ 

7 PQftsJ 

(8 TUV J ( 9 wxyz] 

*del J 1^0 caps / 

/* N 

#, 1 

V 7 


427 Figure 9 - MOTOTRBO™ Portable Keypad 

428 For the received text message as long as the character is supported in Unicode or 

429 UCS-2 LE, it can be displayed correctly on the radio so long as the appropriate 

430 language pack has been installed via CPS. For example \n will be interpreted as line 

431 feed and \r will be interpreted as carriage return. 
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432 8 Subject Line Retention 

433 With MOTOTRBO System Release 1.3, the MOTOTRBO portable and mobile radios 

434 are capable of supporting a subject line within the body of a Simple Text Message. 

435 When replying to or forwarding a text message, the subject line will be retained as part 

436 of the Simple Text Message to the recipient. 

437 8.1 Feature Usage 

438 A subject line is an optional field for the Simple Text Message. If a subject line is used, it 

439 is embedded as part of the Simple Text Message payload and counts toward the 140 

440 character limit for a text message. 

441 To use this feature, delimit the subject line from the text message body with a CR-LF 

442 pair. The CR-LF pair counts as two characters against the 140 character limit for a text 

443 message. Only the text preceding the first occurrence of a CR-LF pair is considered the 

444 subject line of the text message. 

445 8.2 Speciai Cases 

446 The following are special cases to consider when utilizing a subject line: 

447 • Only external Text Messaging applications such as the Motorola Text Messaging 

448 Server or a 3rd Party Text Messaging Application can utilize the subject line 

449 capabilities of a MOTOTRBO™ System Release 1 .3 radio. The MOTOTRBO™ CPS 

450 is not capable of provisioning a subject line in pre-programmed text messages. 

451 Additionally, the radio is not capable of composing a subject line in a new text 

452 message; it can only retain a subject line from a text message that is received. 

453 • A CR-LF pair with no preceding text is considered to have a blank subject line. A 

454 subject line will not be retained by a MOTOTRBO System Release 1 .3 radio when 

455 replying to or forwarding a text message. 

456 • A Simple Text Message received without a CR-LF delimiter must be treated as a text 

457 message without a subject line. The entire contents of the payload must be treated 

458 as a text message body and must not be used when replying to or forwarding a 

459 Simple Text Message. 

460 • MOTOTRBO System Release 1.2, or earlier, radios do not support Subject Line 

461 Retention. A Simple Text Message received by these radios will not be parsed into a 

462 subject line and a text message body. The entire payload will be treated as a text 

463 message body and will not be used when replying to or forwarding a Simple Text 

464 Message. 
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465 9 Use Cases 

466 This section provides some typical use-cases to illustrate the use of the Text Messaging 

467 protocol and interoperation between the TMS application and Presence Notifier. Please 

468 see Reference [1] for more information. 

469 9.1 TMS Wide Area Success 

470 This scenario illustrates how the MOTOTRBO™ radio (MSU - Mobile Subscriber Unit) 

471 powers up on the Radio Network and sends a text message to another subscriber. The 

472 TMS server application provides enhanced delivery of the text message. 


473 

474 


MSCTMS Wide Area Success 
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475 9.2 TMS Wide Area Destination Unavailable 

476 This scenario illustrates how a message is stored in the TMS server when a subscriber 

477 is not available and cannot be contacted for message delivery. The TMS server 

478 application provides enhanced delivery of the text message. When the target subscriber 

479 is not available, the message is stored for later delivery. 


480 

481 

482 


MSC TMS_Wide_Area_Destination_Unavailable 


MSU1 



USUI Pc 
on Data Capa 
ARS Reglstrt 

mere Up 
ble Mode with 
itlon Enabled 


ARS_Device_Reg 


ARS Server 


(Dost Addr: ARS Sarver, Username : USUI ) 


ARS_Red_Resp 


ARS_Deviee_Rea_Ack 


( Dest Addr: USUI, 
Refresh Timer Value, 
Session Timer Value) 


ARSJJpdate 


TMS_Service_Availability_Ack 


TMS_Sknpie_T ex(_Usg 


(Dest Addr TMS Server, Address: MSU2, Seqi 


Num: 0 ) 


Time 

Bettseo- 


Attefnpts 


TMS_Server 


TMS_Se rvk»_A valla Wlty 
(Dest Addr: USUI) 


Store Message 


TMS Ack 


( Dest Addr: USUI, Seq Num: 0) 




Figure 11 - TMS Wide Area Destination Unavailable 
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483 9.3 TMS Wide Area Message Waiting 

484 This scenario illustrates how a subscriber receives messages that are stored in the 

485 server when powering up. The TMS server application provides enhanced delivery of 

486 the text message. Upon detection of the target subscriber, the TMS server application 

487 completes delivery of pending messages. 


488 

489 


MSC TMS_Wide_Area_Message_Waiting 



Figure 12 - TMS Wide Area Message Waiting 
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490 9.4 TMS Direct Send Success 

491 This scenario illustrates how a message is sent between two subscribers in direct mode 

492 {i.e. point-to-point communications in digital RF mode between subscriber units without 

493 use of a repeater). Note that MSU1 in this example is a PC-attached MOTOTRBO™ 

494 radio functioning as a peer to other subscriber units. 



497 9.5 TMS Direct Send Failure 

498 This scenario illustrates how a message failure occurs if the acknowledgement is not 

499 received within predefined period. Note that MSU1 in this example is a PC-attached 

500 MOTOTRBO™ radio functioning as a peer to other subscriber units. 

501 When acknowledgement is required, an Ack Reply Timeout Timer at application layer 

502 {>= 70 seconds) and a Between Attempts Timer (>=3.4 and <=6.75 seconds) at the 

503 data link layer are started. If the acknowledgement is not received before the Between 

504 Attempts Timer expires, a maximum of 3 attempts including the original request are 

505 conducted with the interval of Between Attempts Timer. An error message will be 

506 reported to the application layer or the user after the Ack Reply Timeout Timer expires. 

507 It is up to the application implementation to decide if a retry at the application layer 

508 should be conducted or not. 
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511 9.6 TMS Direct Send Group 

512 This scenario illustrates how a message is sent to a subscriber group in direct mode. 

513 Note that MSU1 in this example is a PC-attached MOTOTRBO™ radio functioning as a 

514 peer to other subscriber units. 



516 Figure 15 - TMS Direct Send Group 
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